How do you put an elephant on a containership in 3 steps?

Open Source Experience
2022-11-08

Who am I

• Lætitia Avrot
• PostgreSQL recognized contributor
• PostgreSQL Europe board member
• #PostgresWomen co-founder
• EDB Field CTO
• @l_avrot@fosstodon.org
• mydbanotebook.org / psql-tips.org

Postgres on containers

• What?
• Why?
• How?
• Is this for me?

Containers are:

• isolated
• light weight
• secured communications
• an encapsulation of all softwares, configuration and librairies

Several technologies

• Docker
• LXC (LinuX Containers)
• Podman
• ...

is that all?

• No
• It goes deeper
• Here comes... Kubernetes!

Kubernetes

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.

Cloud Native PG

• Postgres Kubernetes operator
• Apache 2.0 license
• In the CNCF sanbox

Why?

• Who has standalone Postgres nowadays?
• Who manages less than 5 clusters in production?

➜ More things to do, less administrators

DBA Tasks

• Installations/Configurations
• Securization
• Backup policy implementation
• HA policy implementation
• Minor/Major upgrades
• Monitoring
• Troubleshooting

Changing scripting into configuration

• installation/configurations
• securization
• Backup/HA implementation
• Minor upgrades

And more!

• Self-healing
• Everything in one place
• Service encapsulation
• Self-service for devs

ACID

• Atomicity ✅
• Consistency ✅
• Isolation ✅
• Durability ❌

Stateless/statefull

The way containers are designed, and particularly the way Docker is designed, the assumption is that the container is stateless.

Some tried early...

... And failed

It shouldn't be a reason not to try again!

The key change

Kubernetes 1.14 and persistent volumes

How?

• Declare your configuration
• Deploy
• Relax

Simple

# Example of PostgreSQL cluster
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3

  storage:
    size: 1Gi

Specific Postgres version

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
   # [...]
spec:
   # [...]
   imageName: ghcr.io/cloudnative-pg/postgresql:13.6
   #[...]

Backups

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
# [...]
spec:
  backup:
    barmanObjectStore:
      destinationPath: "[destination path here]"
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: ACCESS_SECRET_KEY

Settings

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
# [...]
spec:
  postgresql:
    parameters:
      shared_buffers: "1GB"
      auto_explain.log_min_duration: "10s"
    pg_hba:
      - host laetitia laetitia all scram-sha-256
  # [...]

Resources

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
# [...]
  resources:
    requests:
      memory: "32Mi"
      cpu: "50m"
    limits:
      memory: "128Mi"
      cpu: "100m"
  # [...]

Rolling upgrades

Triggered when...
• Changing the imageName
• Changing PostgreSQL configuration that needs a restart
• A change on resources
• A change on PVC on AKS
• after an operator update

Logs

• CSV Format (on disk)
• JSON format with kubectl logs

Is that for you?

It depends...

• Is your team experimented with Kubernetes?
• Is your team experimented with Postgres?
• Do you manage more than 5 Postgres clusters?

Caution

Your Postgres database still needs

• Data modeling
• Correct SQL queries
• Careful monitoring

Any questions?